Have I done something stupid with my MiniZinc code (maybe around the mod function)?

Hi  – I was wondering if anyone could shed some light on whether I’ve programmed things incorrectly in MiniZinc.

Main.mzn is my ‘stable’ version, and when I run it (using Gecode and 30 parallel processors) for a small case (k=3) it solves to optimality in less than a second (main.out).

Main_plus_SB.mzn is when I add my symmetry breaking constraints (there are only k-1=2 of them), but when I run that (for k=3) it is 10,000 times slower!! (main_plus_sb.out)

If I turn the symmetry breaking off (so back to Main) but then use an alternative way of constraining n[j] and N to be coprime (Main_alt_Coprime.mzn), it is also insanely slow (main_alt_coprime.out for k=4, where using Main.mzn with k=4 is still around 1 second).

Similarly, if I use a second alternative way of constraining n[j] and N to be coprime (Main_2nd_alt_Coprime.mzn), it is also insanely slow (main_2nd_alt_coprime.out for k=3).

The common element in these three excursions from Main.mzn seems to be using the mod function. So I was wondering if it had something to do with the mod function in MiniZinc?

Anyhow, I was hoping that by illustrating this issue with very small examples and highlighting what the code changes are, someone more fluent in MiniZinc coding might be able to work out what is going on.

If you spot anything amiss, please let me know.

Andrew